Day 23 把 Webhook 打通了，對話資料已經能從前端送到 n8n，還被整理成一段完整的文字。但這時候資料只是「被收到」而已，沒有人真正去看它、分析它。今天要接上整條自動化流程裡最關鍵的一步：讓 n8n 自動把對話丟給 LLM，產出英文錯誤分析與自然表達推薦。

這也是整個專題最能體現「AI 自動化」四個字的地方：使用者什麼都不用做，對話一結束，分析自己就跑出來了。

流程現況：目前接到哪裡

把手上已經完成的部分攤開來看：

Webhook 接收使用者按下「結束對話」後送出的資料
一個整理節點，把訊息陣列轉成一段完整文字

今天要在後面接上第三個節點，負責呼叫 LLM。

用 HTTP Request 節點呼叫 LLM

n8n 呼叫 LLM 有兩條路：一種是用內建的 AI 相關節點，另一種是用最通用的 HTTP Request 節點，自己指定要打哪個 API。

今天選擇了後者，原因有兩個：一方面這樣能直接用上 Day 8、Day 15、Day 16 累積的 API 概念，不是黑箱地點幾個按鈕就算數；另一方面，之後如果想換不同的模型，只要改網址和 Header，不用重新換節點。

節點設定上，每一格都能對應到前面學過的東西：

Method：POST，因為是送出一段文字請 AI 處理
URL：LLM 服務的 endpoint
Headers：放 Authorization（API Key）和 Content-Type，Day 16 在 Postman 踩過的空格坑,這次直接避開了
Body：用 JSON 格式，把上一個節點整理好的對話文字，連同要求 AI 做什麼的指令，一起包進去

這裡最有感的一點是：n8n 讓我能用「{{ }}」這種語法，把前一個節點的輸出直接帶進這個節點的 Body 裡，不用手動複製貼上，這就是 Day 6、Day 7 學過的「資料在節點之間傳遞」概念，今天第一次實際派上用場。

分析用的 Prompt 怎麼設計

呼叫 LLM 最重要的當然是丟進去的 Prompt。這個 Prompt 的設計邏輯，整個沿用 Day 12、Day 13 累積下來的經驗：

角色設定：讓 AI 扮演「一位懂英文教學、也了解母語者實際用法的英文老師」。

任務說明：清楚講要分析使用者在對話中說的每一句英文，找出文法錯誤，並且給一個更自然的母語者說法。

難度跟語氣的限制：這次也記得 Day 14 測試時發現的問題，把「語氣要配合對話情境的正式程度」這條規則明確寫進去。

輸出格式：同樣要求結構化的 JSON，包含「原句」「修正後」「更自然的說法」「簡短說明」這幾個欄位，並且嚴格規定不能加任何前言或多餘的客套話——這是 Day 7 到 Day 14 反覆踩過的坑，這次一開始就寫進規則裡。

今天遇到的三個狀況

狀況一：只分析 AI 說的話，沒分析使用者說的話

整段對話文字裡包含了雙方的發言，第一次測試時，AI 把雙方的句子都拿來「修正」，連 AI 自己講的話都在挑錯。這是因為整理節點把兩邊的訊息混在一起，沒有標示清楚誰是誰。回頭修改 Day 23 的整理節點，在每句話前面標註說話者，並且在分析 Prompt 裡明講「只分析 User 的句子」之後解決。

狀況二：回傳的 JSON 在 n8n 裡沒辦法直接取用

LLM 回傳的內容是一整段文字（雖然看起來是 JSON 格式），n8n 把它當成純文字，沒辦法直接拿裡面的某個欄位出來用。後來要多加一個節點，把這段文字解析成真正的 JSON 物件，後面的節點才能取用裡面的「修正後」「更自然的說法」這些欄位。這也回頭印證了 Day 9 的觀念：文字長得像 JSON，跟真的是 JSON 資料，是兩回事。

狀況三：對話太長時，分析結果變得籠統

拿一段比較長的對話測試，AI 傾向挑出幾個最明顯的錯誤就停了，細微的不自然表達常常被略過。目前先接受這個限制，記下來當作之後的優化項目，不在今天硬著頭皮解決。